【都市封鎖に備える】オフィスにあるデスクトップに自宅からリモートアクセスして業務継続する方法【ネットワーク編】

リモートワーク（テレワーク・在宅勤務）

#RDP

#Amazon VPC

#DR/BCP

#VPN

#セキュリティ

トラン

2020.04.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、トランでございます。皆さんいかがお過ごしでしょうか?

COVID-19の影響でヨーロッパでは地域によっては外出が制限され、オフィスに物理的に集合して仕事をすることが難しくなっています。

リモートワークの導入には様々な手法があり提案されていますが、クラウド化が進んでおらず、端末がデスクトップでLANとオンプレミスサーバーを前提にした業務環境は少なくはなく、緊急事態での切り替えは困難を極めます。

きょうはそういった困難を抱える企業向けの即効性のある事業継続策として、AWSを使ってオンプレミスのデスクトップ環境にホームオフィスからアクセスできるようにする方法についてご紹介したいと思います。

前提

オンプレミス、いわゆる拠点に置かれたリソース、すなわちデスクトップ PC や内部アプリケーションに外部からアクセスする方法として、大きく分けて «ゲートウェイ型のソリューション» と «VPN 型のソリューション» があります。

一般的に«ゲートウェイ型のソリューション»では、拠点に置かれたリソースに対して RDP や HTTP のアクセスを提供するためにアプリケーション固有のゲートウェイを実装することで外部から内部へのアクセスを可能にします。頻繁に実装されるソリューションとしては、ドメイン認証を有効にした Web アプリケーションプロキシや RD (リモートデスクトップ) ゲートウェイが挙げられます。

これらのソリューションはアプリケーションにネイティブなものであるため従業員がシームレスに利用できるという利点がありますが、一つひとつのアプリケーションに対してそれぞれゲートウェイを構成しなければいけないという致命的な欠点があります。

例えば、携帯電話のテザリングや公衆無線 LAN から社内のリソースを利用するケースを想像してみてください。社内のリソースとして、以下のようなものが考えられます。

Web アプリケーション。IIS や Apache でホストされたもので、社内からしか利用できないもの。
ファイルサーバーなどのディレクトリと密結合したLAN上のネットワークドライブ。
RDP や SSH などのコンソール環境。おもに VDI、もしくは社内サーバーに対する管理アクセスなど。
ネットワークコンポーネントに対する Telnet や SSH。ファイウォール、ルーターやスイッチなど。
それ以外のアプリケーションに対するアクセス。

正直に申し上げて、これらそれぞれのアプリケーションに対してゲートウェイ型のソリューションを実装する方法には無理があります。加えて、テレワークが欠かせないものである昨今の事業環境において、ホームオフィスから業務を行うからといってアクセスできないアプリケーションがある状況は明らかに容認できるものではありません。

一方、«VPN 型のソリューション» を実装する場合、任意のリモートユーザーに対して あらゆる 内部アプリケーションへのアクセスを一括で提供できます。VPN 型のソリューションはゲートウェイ型のソリューションに比べてオーバーヘッド* が大きいためパフォーマンスが重視される場面では懸念が生じますが、そうでない場面ではリモートユーザーが『拠点のネットワークへ接続しているかのように』さまざまな内部アプリケーションを利用できるという利点があります。

これらを踏まえ、今回は 拠点に置かれたデスクトップ PC にリモートユーザーがアクセスする手段を提供する 方法についてご紹介したいと思います。

イメージ

今回実装するソリューションのイメージは、以下の通りです。あらかじめ作成した Amazon VPC とオンプレミスのネットワークの間で Site-to-Site VPN を作成し、インターネットから VPC 上に作成した EC2 インスタンスを経由する形でオンプレミスのデスクトップ PC へアクセスできるようにします。

準備

今回は、新しい Amazon VPC を作成したうえでオンプレミスとの接続性を Site-to-Site VPN で確立します。

Amazon VPC コンソール (https://console.aws.amazon.com/vpc/) を開き、VPC ウィザードの起動を選択します。
パブリックとプライベートサブネットおよびハードウェア VPN アクセスを持つ VPCを選択します。
新しく作成する VPC の属性を指定します。今回は、10.0.0.0/16 の IP アドレスレンジをオンプレミスで使用していないこと* を前提として以下のような要領で VPC を作成します。これだけで、オンプレミスとつながった VPC を用意することができます。

*オンプレミスで 10.0.0.0/8 の IP アドレスレンジを使用している場合は絶対に被らないようにしましょう。拠点やグループ会社が多数あり使用可能な IP アドレスレンジを特定することが難しい場合は、100.64.0.0/10 の Carrier Grade NAT レンジから無作為なレンジを使用するのがお勧めです。

引き続き Site-to-Site VPN のための属性を指定します。カスタマーゲートウェイ IPとしてオンプレミスのグローバル IP アドレス、ルーティングの種類として静的* を選びましょう。併せて、オンプレミスで使用している IP アドレスレンジを VPN 接続に対して登録しておきます。よくわからない場合、以下の要領で RFC 1918 のレンジを登録しましょう。 *今回は便宜上 «静的» のルーティングを指定しましたが、高い可用性が求められる場面では «動的 (BGP が必要)» を選びます。
VPC の作成を選択してしばらく待つと、«VPC は正常に作成されました» の画面が表示されます。続いて «サイト間の VPN 接続» のページへ移動しましょう。
作成された VPN 接続を選択し、設定のダウンロードを選択します。
«設定のダウンロード» では、オンプレミスから VPC への接続に使用したいデバイスを選択します。選択したデバイスは Site-to-Site VPN 接続自体の設定 (ISAKMP や IPsec のパラメーター) には影響を与えず、あくまで設定のサンプルをダウンロードするデバイスとして扱われます。
設定のサンプルがダウンロードできたら、オンプレミスのルーター、もしくはファイアウォールに設定を入れます。よくわからない、もしくはルーターやファイアウォールがサービスプロバイダーやリセラーによって管理されている場合、しかるべき窓口へ迷わず相談しましょう。
オンプレミスから VPC への VPN 接続が確立できたら、VPC のルートテーブルを編集しましょう。VPC コンソールのルートテーブルから、VPC ウィザードによって作成された «メインでない» ルートテーブルを探します。メインでないルートテーブルには、インターネットへのルートがあります。特定できたら、ルートの編集を選択しましょう。
«ルートの編集» では、オンプレミスへのルートを登録します。オンプレミスで使用している IP アドレスのレンジがわかっている場合はそれを、よくわからない場合は以下の要領で RFC 1918 のレンジを登録しましょう。これで、VPC 上の «パブリック» サブネットからオンプレミスのリソースへ接続できるようになりました!